Subject: circuit collision

From: [email-masked]
Date: Mon, 11 Apr 94 12:19:34 EDT

To answer G. Pandian's question, no I don't think we have reached a
resolution on which solution to adopt for handling circuit collision.
It's hard for Steve to push this since he's the author of one of the
proposals, so I thought I would recap where we left this at AIW4 and
solicit your comments.  How about if interested parties comment by
Monday 4/18 so we can make a decision on this item?

The latest relevant posts on this issue (after Bernie Brady's initial
ones) are from:
   Steve Klein on Mon, 7 Feb 1994 17:16:02
     Counter proposal to Bernie's originals
   Bernie Brady on Tue, 8 Feb 1994 10:07:37
     Update to his own proposal, response to Steve's
   Laksham Garikapaty on Thu, 10 Feb 1994 07:42:11
     Question to Bernie, vote for modification of Steve's proposal

My summary of the proposals (corrections welcome):
- Bernie Brady's:
  Both DLSw's detect the race condition possibly at CUR time, and
  both continue their link establishment logic.  New logic is required
  to respond to ICANREACH with REACH_ACK in CIRCUIT_PENDING state,
  By using the frame direction field (i.e., both get a REACH_ACK with
  01 and swapped circuit id's), each DLSw detects the REACH_ACKs map
  to a single circuit.  Only one circuit is established.

  Bernie states that his mechanism works when one of the nodes is
  RFC 1434, since such nodes ignore the collision.

- Steve Klein's:
  When two DLSw nodes receive a CUR for a data link id they just sent
  a CUR to, each performs a contention resolution algorithm to determine
  who will continue the link establishment request.  The proposed
  algorithm is that the CUR with the highest (ignoring the RII bit)
  origin MAC address should continue.  So each node does this comparison
  and the receiver of the "winning" CUR will respond with an ICR.  The
  receiver of the "losing" CUR discards it.

  When one of the nodes is RFC 1434 and does not have this comparison
  logic, the other (uplevel) node discovers this through capabilities
  exchange.  When the uplevel node detects a race condition, it will
  always discard the received CUR (without MAC address comparison) and
  and allow the backlevel node to be the ICR sender.

- Laksham Garikapaty's:
  The same as Steve's except compare IP addresses being used for the
  transport connection to determine contention winner.

Discussion at AIW4:
- Steve clarified how his proposal could handle the case of an RFC1434-
  level node, which I mentioned above.  This was not in his 2/7 note
  and Bernie correctly pointed out this weakness in his 2/8 note.
- Some felt that using MAC addresses was preferable to IP addresses, so
  as not to create an issue for when someone wants to move the DLSw
  SSP protocol to a transport other than TCP.  I believe someone from
  Cisco raised a concern that the use of MAC addresses might be a prob-
  lem for some automatic MAC assignment scheme for SDLC stations.
  Later in the SDLC discussion, I think the same person said they might
  describe this scheme as part of the RIG's SDLC deliberations.
- Some people suggested that SAPs need to be included with MAC addresses
  for comparison.
- Partially due to shortness of time, the issue was deemed suitable for
  e-mail resolution and was tabled.

My personal opinion (to get the discussion going):
- I prefer Steve's proposal with MAC address comparison, because I feel
  it is simpler and more robust.  Both proposals work, but as I went
  through the FSMs with Bernie's flow diagram, it seemed as if there
  wasn't just one but now several states where you now had to think
  about new conditions.  For example, it seemed that one now needed
  to be prepared to pick up the partner's full circuit id from the ICR
  in CIRCUIT_PENDING or REACH_ACK in CIRCUIT_ESTABLISHED or CONNECT_
  PENDING states.  This is trivial, but my point is there are more
  frames coming in "unnatural" places for longer, and my instincts say
  this should be avoided if possible.
    It is also not completely clear to me how Bernie's scheme interoper-
  ates with backlevel nodes.  RFC1434 doesn't require handling ICANREACH
  in CIRCUIT_PENDING state, but it or the REACH_ACK are needed to pick
  up the remote circuit id.  In any case, it seems likely to me that
  some RFC1434 implementations would not handle Bernie's flows as shown.
- I would like to avoid the use of IP addresses, to increase the chances
  of running the SSP over some other transport in the future.  I dis-
  agree with Lakshman's 2/10 assertion that there is no concept of
  MAC addresses in the SDLC-SDLC case, since MAC addr's are the means of
  identifying end stations in the SSP messages.  If someone has a scheme
  that this breaks, are they saying that their scheme does not assure
  MAC address uniqueness in the DLSw network?
- I don't see any need to include SAPs in the address comparison.  SAPs
  must be included in the test that detects the race condition, but to
  resolve it we do not need values that uniquely identify this circuit,
  just some piece of info both routers have that can break the tie.

Please state your opinion on these issues and let's see if we can reach
a consensus one way or the other.

Peter Gayek

---

From: Gnanaprakasam Pandian <[email-masked]>
Date: Mon, 11 Apr 94 15:48:16 PDT

>   some RFC1434 implementations would not handle Bernie's flows as shown.

I am comfortable with steve's proposal.

>   MAC address uniqueness in the DLSw network?

Not us. I would go for MAC address based comparisons.

>   just some piece of info both routers have that can break the tie.

Me neither.

> Peter Gayek
Last but not least,
I see some other places as well where the fsm has to handle collisions.
	CONNECT_PENDING state. ( waiting for a contacted message )
		Receipt of CONTACT - transition to CONNECTED
	DISCONNECT_PENDING state ( waiting for DL_HALTED )
		receipt of HALT_DL - transition to DISCONNECETD
thanks

-- 
G. Pandian           + Gnanaprakasam Pandian      +
Cisco Systems, Inc.  + Software Engineer          +           
1525 O'Brien Drive   + Phone : (415)688-7684      +
Menlo Park,          + FAX   : (415)688-8282      +
CA 94026             + E-mail: [email-masked] +